home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1143 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.4 KB
  1. Path: fido.asd.sgi.com!austern
  2. From: David Brownell <brownell@ix.netcom.com>
  3. Newsgroups: comp.programming.threads,comp.std.c++
  4. Subject: Re: Is STL MT-Safe?
  5. Date: 17 Apr 1996 13:08:11 PDT
  6. Organization: Dave's VAX
  7. Approved: austern@isolde.mti.sgi.com
  8. Message-ID: <31753C02.58A6@ix.netcom.com>
  9. References: <4kmjvj$89t@usc.edu> <4kspmb$9tb@ubszh.fh.zh.ubs.com> <3173E95E.5AC@ix.netcom.com> <4l12rf$q11@galaxy.ucr.edu>
  10. NNTP-Posting-Host: isolde.mti.sgi.com
  11. X-Original-Date: Wed, 17 Apr 1996 11:44:18 -0700
  12. X-Netcom-Date: Wed Apr 17  1:45:13 PM CDT 1996
  13. X-Mailer: Mozilla 2.0 (Win95; I)
  14. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  15.     iQBVAwUBMXVPrUy4NqrwXLNJAQHFSQIAvHTBaxu3Z8BYZ9wgY1d6+0i4P8x7wnQJ
  16.     mFtBWEkncS943JfAykSDhRwxgDvSXV9mzc0hpjDxN6RE+8YLCA4H9w==
  17.     =AD8i
  18. Originator: austern@isolde.mti.sgi.com
  19.  
  20. Tom Payne wrote:
  21. > 
  22. > David Brownell (brownell@ix.netcom.com) wrote:
  23. > :
  24. > : Someone else mentioned Rogue Wave.  Does anyone have URLS or something
  25. > : through which the different "MT-enhanced" APIs could be compared?  I've
  26. > : been organizing a collection of MT/C++ issues; one of the gaps is where
  27. > : the standard C++ library interfaces need to be "MT-safed" according to
  28. > : some useful and consistent policy.
  29. > 
  30. > Is there agreement on what is meant by the term "thread safe."  (I have
  31. > seen definitions that seemed quite inadequate.)
  32.  
  33. IMHO "Thread-safe" is a misleading goal.  You actually want an API that's
  34. natural to use in a threaded environment ... in some cases, that means an
  35. API that's OK to use from concurrent threads (e.g. add to containers),
  36. but in other cases it's reasonable to have objects that are only usable
  37. from a single thread (e.g. iterators).
  38.  
  39. Consider for example POSIX.1c "putc_unlocked()" ... not thread-safe by itself,
  40. but very usable for high performance character I/O since it's always used in
  41. conjunction with "flockfile()" (in non-erroneous programs).
  42.  
  43. (See my writeup at http://www.netcom.com/~brownell/pthreads++.html for some
  44. discussion of the "policy" that a useful MT-safe version of the standard
  45. C++ library ought to follow.  It also covers a bunch of other C++/MT issues
  46. that come up in the POSIX.1c/C++ environment.  Comments, please!)
  47.  
  48.  
  49. > : Eventually, the vendors ought to agree on one way to do threaded C++,
  50. > : but we're not there yet!  I don't know how much commonality there is
  51. > : between different MT/C++ environments but I suspect it's not lots.
  52. > 
  53. > The standards process is the appropriate forum for such vendor
  54. > agreement.  Unfortunately, the standards bodies have failed to provide
  55. > the necessary leadership in the areas involving concurrency and
  56. > asynchrony.  Perhaps, these bodies simply have other fish to fry --
  57. > getting the current standard completed is an monumental task.
  58.  
  59. Well, POSIX.1c happened; it's the ANSI/ISO C++ team that's said such
  60. issues are "out of scope" for now.  I don't think it's realistic to
  61. expect POSIX to produce a C++ binding at this time, given some of the
  62. issues raised in my writeup above.  Nor do I think vendors should be
  63. gratuitously diverging, even lacking a formal standards framework.
  64.  
  65. >      I
  66. > detect, however, some reluctance to address matters of concurrency and
  67. > asynchrony for fear of:
  68.  
  69. Hmmm, "concurrency" and "asynchrony" are broader issues than threading.
  70. Many people use threading to _avoid_ asynchrony, for example.
  71.  
  72. >   ...
  73. > 
  74. > Although each of these fears has some arguments for it, the portable
  75. > implementations of Modula and Ada offer evidence that the difficulties
  76. > are surmountable.  Meanwhile, a C++ program (with defined behavior)
  77. > cannot deal efficiently with some of the simplest asynchrony, e.g., a
  78. > hardware-detected exception cannot generate a program exception,
  79. > unless the program explicitly polls for it, thus, requiring
  80. > unacceptable overhead both in running time and programming effort.
  81.  
  82. Some of us don't think that it's necessarily a good thing to complicate
  83. C++ exception processing further -- it's a synchronous mechanism now.
  84. I'd hope that the current mechanism for asynchrony (signals) would just
  85. be fixed to address your issues!
  86. -- 
  87. David Brownell
  88. http://www.netcom.com/~brownell
  89. ---
  90. [ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
  91.                 newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  92.   comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  93.   Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  94.   Comments? mailto:std-c++-request@ncar.ucar.edu 
  95. ]
  96.